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1 INTRODUCTION 

The purpose of this case study is to review alternatives for accessing dis- 
tributed heterogeneous databases and propose a recommended solution. Our 
current study is limited to the Automated Information Systems Center at 
the Naval Sea Combat Systems Engineering Station at Norfolk, VA. This 
center maintains two databases located on Digital Equipment Corporation’s 
VAX computers running under the VMS operating system. The first data 
base, ICMS, resides on a VAX 11/780 and has been implemented using VAX 
DBMS, a CODASYL based system. The second database, CSA, resides 
on a VAX 6460 and has been implemented using the ORACLE relational 
database management system (RDBMS). 

Both databases are used for configuration management within the U.S. 
Navy. Different customer bases are supported by each database. ICMS 
tracks U.S. Navy ships and major systems (anti- air, weapons launch, etc.) 
located on the ships. CSA tracks U.S. Navy submarines and the major 
systems located on the submarines (anti-sub, sonar, etc.). Even though 
the major systems on ships and submarines have totally different functions, 
some of the equipment within the major systems are common to both ships 
and submarines. 
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2 PROBLEM STATEMENT 

Even though the two databases are physically distinct, there a number of 
external actions which affect the data in both databases. Keeping the data 
consistent across these databases is a major problem. For example, the 
same computer is used within many major systems on ships and submarines. 
Thus, both CSA and ICMS maintain this information about this computer in 
their respective databases. If the U.S. Navy decides to stop buying parts for 
this computer from the existing supplier and start buying from an alternate 
supplier, this information needs to be updated in both databases. It should 
be noted that the two VAX’s communicate via DECNET and that critical 
data must be updated in real-time up to 2 hours; all other data must be 
updated on a daily basis. 

3 PROPOSED ALTERNATIVES 

We propose two alternatives. 

(1) A global data manager (GDM) resides on one machine and all update 
transactions (to either of the systems) are routed through this cen- 
tral location. Any transaction that affects only one database is sent 
directly to the affected database. Since non-critical updates may be 
propagated on a daily basis, it is possible to send them directly to the 
affected database. 

(2) Require each system to log all local transactions. Each system would 
have a local agent GDM that would regularly review each local database 
log and determine if a remote database transaction should be gener- 
ated. The GDM would also report in the database log, the status of 
any transactions issued remotely. This alternative is the most viable 
for this environment. The GDM is primarily an initiator of transac- 
tions to keep the databases synchronized. The GDM also monitors 
the results of the initiated transactions and records the results in the 
originating database log. The local data managers (LDM) would be 
solely responsible for local transactions and local concurrency control. 

The latter alternative appears to be more suitable for the current environ- 
ment. 
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4 Sample Data 

The ICMS database consists of records, data items and sets. An example of 
affected records sets and data items is given below. 

SCHEMA NAME IS ICMS.SCHEMA 

RECORD NAME IS SITE.DESCRIPTION 
WITHIN SITE.INFO 

ITEM SITE.IDENTIFICATION TYPE IS CHARACTER 15 

RECORD NAME IS SYSTEM.DESCRIPTION 
WITHIN SYSTEM.INFO 

ITEM SYSTEM.NAME TYPE IS CHARACTER 26 
ITEM SYSTEM.AINAC TYPE IS CHARACTER 2 
ITEM SYSTEM.FSCM TYPE IS CHARACTER 5 
ITEM SYSTEM.PART.NO TYPE IS CHARACTER 26 
ITEM SYSTEM.STOCK.NO TYPE IS CHARACTER 26 
ITEM SYSTEM .CATEGORY TYPE IS CHARACTER 5 

RECORD NAME IS SYSTEM .INST ALL AT ION. ST ATUS 
WITHIN INST.AREA 

ITEM SYSINST.STATUS TYPE IS CHARACTER 1 
ITEM SYSINST.SITE.ID TYPE IS CHARACTER 15 
ITEM SYSINST.SYSTEM.NAME TYPE IS CHARACTER 26 
ITEM SYSINST.SERIAL.NUMBER TYPE IS CHARACTER 15 

SET NAME IS ALL. SITES 
OWNER IS SYSTEM 
MEMBER IS SITE.DESCRIPTION 
INSERTION IS AUTOMATIC RETENTION IS FIXED 
ORDER IS SORTED BY 

ASCENDING SITE.IDENTIFICATION 
DUPLICATES ARE NOT ALLOWED 

SET NAME IS SITE.SYSTEM.INST.STAT 
OWNER IS SITE.DESCRIPTION 
MEMBER IS SY STEM .INSTALLATION. ST ATUS 
INSERTION IS AUTOMATIC RETENTION IS FIXED 
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ORDER IS FIRST 


SET NAME IS SYSTEM.SITE.INST.STAT 
OWNER IS SYSTEM.DESCRIPTION 
MEMBER IS SYSTEM_INSTALLATION_STATUS 
INSERTION IS AUTOMATIC RETENTION IS FIXED 
ORDER IS SORTED BY 

ASCENDING SYSINST.SERIAL.LETTERS 
SYSINST.SERIAL.NOS 
DUPLICATES ARE LAST 

SET NAME IS ALL.SYSTEMS 
OWNER IS SYSTEM 
MEMBER IS SYSTEM.DESCRIPTION 
INSERTION IS AUTOMATIC RETENTION IS FIXED 
ORDER IS SORTED BY 

ASCENDING SYSTEM.NAME 
DUPLICATES ARE LAST 

The CSA database consists of tables and data items. Examples of tables 
and data items are given below. 


TABLE: SITE 

Name Null? Type 


SITE. IDENTIFIER CHAR(15) 

SQUADRON CHARC30) 

CONFIG.DATA.MANAGER CHAR(20) 

TYPE.COMMANDER CHAR(14) 

FLEET.CODE CHAR(l) 

STD.NAVY.DIST.LIST CHAR(8) 

LOCATION CHARC30) 


TABLE: NOMEN. ITEM 

Name Null? T yP« 


4 



CATEGORY.TYPE.CODE 

PROGRAM.MANAGER 

TECHNICAL.MANAGER 

S Y STEM _ I NTEGRATI 0 N .AGENT 

DESIGN .AGENT 

ACQUISITION.ENG. AGENT 

TECHNICAL.DIRECTION. AGENT 

IN.SERVICE_ENG_AGENT.CODE 

IN_SERVICE_ENG.AGENT_PHONE.NUM 

IN.SERVICE.ENG.AGENT 

SPCC.ITEM.MANAGER.PHONE.NUMBER 

SPCC.ITEM.MANAGER 

DATE.UNDER.CONFIG.CONTROL 

DATE.OF.LAST.UPDATE 

TEST.AND.EVALUATION 

BRIEF.NAME 

FULL.NAME 

NOMEN 


NOT NULL CHAR(5) 
CHARC14) 
CHAR(14) 
CHAR(14) 
CHAR(14) 
CHAR(14) 
CHAR(14) 
CHAR(14) 
CHAR(12) 
CHAR (14) 
CHAR(12) 
CHAR (40) 
DATE 
DATE 
CHAR (14) 
CHAR(50) 
CHAR(70) 
NOT NULL CHAR(26) 


TABLE: SITE.INSTALLATION 
Name 


BELONGS.TO_SITE.ID 
SERIAL.NBR 
SERIAL .NUMBER 
SERVICE. APPLIC.CODE 
NOMEN 


Null? Type 


NOT NULL CHAR(14) 
CHAR(15) 
CHAR (15) 
CHAR(IO) 
CHAR(26) 


5 IMPLEMENTATION 

The following implementation scheme is proposed to implement the second 
method. 

A. Log all local transactions that relate to both databases. There will be 
one log per database and the log contains a timestamp of when the 
local transaction was committed, the node name, transactions (add, 
update, delete) and records/tables affected and data items affected. 
The key to all transactions is the system/unit nomenclature. 
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B. Modify each application program, that alters data, to log each trans- 
action after it is committed. Sub-transactions must be entered into 
the log in the order they were executed on the local machine. 

C. Generate list of system/equipment nomenclatures that are common 
between each database. The list would reside in a centralized loca- 
tion that would contain nomenclatures that are shared between each 
database. The Database Administrator (DBA) would maintain the 
nomenclature list. 

D. Develop GDM to review the log files and search for transactions against 
common nomenclatures. After the GDM determines the transaction 
must be issued globally, it generates a remote transaction to be exe- 
cuted on the remote machine. GDM must know how to translate a 
transaction to be executed on another database. 

E. The GDM must formulate the transaction in the appropriate data 
manipulation language so it can be executed on the affected database. 

F. The GDM must send through DECNET a transaction package that 
will execute on the remote machine as a batch job. Set up account 
on each system for remote system to use to go into and submit batch 

jobs from. 

G. The LDM will execute the transaction package as if it were generated 
locally. 

H. When the transaction completes, the batch program will send a mes- 
sage back to the originating machine signifying that the transaction 
has completed. Once the message is received, the transaction is re- 
moved from the log. Generate a process to run on the other machine 
to update the log file. 

I. Crash Recovery Procedures - As soon as a system recovers from a 
crash, a message will be sent to the other system to signal that pro- 
cessing can continue. The GDM will resend any transactions packages 
that it did not receive a completion on. If database commits and then 
crashes before sending a message, need to determine what to do. 
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6 RECOMMENDATIONS 

The situation exists that two data bases that have multiple occurrences of 
the same data must learn to co-exist and keep each other informed of any 
changes to their duplicate data by keeping a log file, the internal database 
processing software is not affected. The application programs are responsible 
for logging the affects of the program. 
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